dpd's inet dlz 20180419a #133
Conversation
allow for duplicate A/AAAA duplicate records.
Allowing MX, NS and CNAME records to point to external domains is needed
for example, for Gmail/GSuite MX Records. Also, if having other 3rd party
cloud services, this is sometimes needed. Footer files are a solution,
however not for BIND-DLZ server, and for single source of truth.
This is an optional config, and when not enabled should have a NOOP effect:
"allow_external_pointsto" => 1
HOWEVER - this does slightly break build-bind, and I have not yet provided
patches.
Allow Duplicate A,AAA records for the poor man's loadbalanceing with
Round-Robin DNS. This too could be done with footers, however, in the
spirit of a single source of truth - allowing this to be in the database
as well as allowing BIND-DLZ to server it.
"allow_duplicate_arecords" => 1
as well as A/AAAA round robin.
|
I added two more features that I need for managing IPs and DNS. First, allowing MX, NS and CNAME to point to external domains. This is needed, for example, for Gmail/Gsuite. Of course, footer files can do this, however, those wouldn't be seen by BIND-DLZ. Additionally, this was a second place to manage DNS. Second is duplicate A records, for round robin DNS. This behavior is controlled by config, and shouldn't interfere with anything if not enabled. Note, pointing records to external domains makes a slightly bad build_bind output. Build_bind needs to be patched to know about allow_external_pointsto, and I have not provided that patch. |
|
Very interesting.. I'll have a look at things and see how it fits in with the whole thing. Thanks for sharing this. I do want to mention that I was putting in some work on the external DNS reference thing. It is currently contained in the following branch: https://github.com/opennetadmin/ona/tree/feature_finaly Basically it adds a column to the dns table that when a 'points to' value is not avalable, it would use the data in this field as the raw data for the DNS record. This is the direction I'm heading with things and it would of course require updates to the build_bind and build_tinydns modules. Any DLZ type setups would need to have a similar adjustment to the SQL statement that pulls out the data. my intent is to have them all share as much of that same basic SQL select logic as possible. Anyway, I wanted to mention that for what it is worth to ensure things can remain headed in the same direction as much as possible. :) Thanks again, I'll try and dig in on this soon.. my next priority is to get ONA working on newest php7.x versions etc (basically when Ubuntu 18.04 comes out) |
|
Thanks Matt. Will look at the branch. BTW - PHP 7.2.x on FreeBSD is running fine, other than the 1 array assignment and the session handler. If there were more PHP 7.x issue, I've should have hit it by now. Also, note this branch/pull request - also fixes a number of PHP Warnings and Notices - I run with all errors being logged, as both in PHP and Perl, I've found correcting these, sometimes solves some random, hard to find bugs. I will look at your branch, and see how it integrates, and see if it makes sense replace my changes with yours. After spending some time in the code ... there are many many things that need some love, and would love to chat on a side channel / email, as well as understanding some design choices. |
See
docs/DPD-DLZ-INET-Chanages.mdwithin this branch for more information, but in short, this will allow BIND-DLZ to use ONA's database directly, without any views, with all queries using indexes ... and supporting full v6, both v4/v6 reverse lookups (PTRs), and return NS, SOA, and MX records correctly.An auto upgrade path is not provided, I assume that would need to be formalize more at the time of merged and just before tagging for a release. However,
install/inet-functions.sqlneeds to be applied to the database, before runninginstall/inet-functions.php.Backwards compatibility should have been retrained, so the changes shouldn't affect any other modules, plugins or code path, but extensive QA has not been done. I don't expect this patch set to be merged as-is, but wanted to share with community as soon as I had it available.
Please let me know any changes that would be required for getting this upstreamed.
I've created this additional and patches as part of my employment as Director of Information Technology at iX Systems, Inc. I'll be using my fork-and-branch (pending upstreaming merging) to deployed a new US nation-wide internal DNS system for company.